为了避免死锁和数据破坏&＃xff0c;千万不要从同步区域内部调用外来方法&＃xff0c;同时要尽量限制同步区域内部的工作量。

从 Java5 开始引入了 Executor Framework&＃xff0c;这是一个灵活的基于接口的任务执行工具&＃xff0c;执行的是 Runnable 或 Callable&＃xff08;后者有返回值&＃xff09;。

在实际做项目时&＃xff0c;不推荐使用 Executors 去创建线程池&＃xff0c;而是通过 ThreadPoolExecutor 的方式。为什么呢&＃xff1f;Executors 返回的线程池有一些缺点&＃xff1a; 1. FixedThreadPool 和 SingleThreadPool: 允许的请求队列长度为 Integer.MAX_VALUE&＃xff0c;可能会堆积大量的请求&＃xff0c;从而导致 OOM。 2. CachedThreadPool 和 ScheduledThreadPool: 允许的创建线程数量为 Integer.MAX_VALUE&＃xff0c;可能会创建大量的线程&＃xff0c;从而导致 OOM。

代码不受约束是很可怕的事情。

从本质上将&＃xff0c;Executor Framework 所做的工作是执行&＃xff0c;犹如 Collections Framework 所做的工作是聚集一样。

wait 和 notify 有什么缺点呢&＃xff1f; 1. 只有一个资源&＃xff0c;但是可能用 notify all 唤醒了所有等待线程。 2. 在没有通知的情况下&＃xff0c;等待线程也可能苏醒&＃xff0c;被称为虚假唤醒 spurious wakeup。

wait 的标准用法如下&＃xff1a;

synchronized (obj) {while (condition does not hold) {obj.wait(); // 释放锁&＃xff0c;等待被唤醒}// 执行其他操作}

始终使用 wait 循环模式调用 wait 方法&＃xff0c;循环会在等待之前和之后测试条件。

在有现成的并发工具时&＃xff0c;不要自己用 wait、notify 去控制并发&＃xff0c;比如用 ConcurrentMap&＃xff0c;好过自己控制并发。ConcurrentMap 相对于 Collections.synchronizedMap 性能更好。

当一个类的实例或静态方法被并发使用的时候&＃xff0c;这个类的行为如何&＃xff0c;是该类与其客户端程序建立的约定的重要组成部分。如果没有在文档中描述类的并发性情况&＃xff0c;使用这个类的程序员将不得不做出某些假设。如果假设错误&＃xff0c;可能导致缺少同步&＃xff0c;或过度同步。

线程安全有多种级别&＃xff1a; 1. 不可变的 immutable&＃xff1a;String、Long、BigInteger。 2. 无条件的线程安全&＃xff1a;无需任何外部同步&＃xff0c;比如 Random、ConcurrentHashMap。 3. 有条件的线程安全&＃xff1a;部分方法需要外部同步&＃xff0c;比如 Collections.synchronizedMap 的迭代器。 4. 非线程安全&＃xff1a;比如 ArrayList 和 HashMap。 5. 线程对立的&＃xff1a;外部同步也白搭的&＃xff0c;不能线程安全地被多个线程并发使用。

在无条件的线程安全中&＃xff0c;需要使用私有锁对象&＃xff0c;防止外部客户端访问锁&＃xff0c;影响对象的同步。私有锁对象特别适合于那些为继承而设计的类&＃xff0c;如果使用自身实例作为锁&＃xff0c;子类很容易在无意中妨碍基类的操作&＃xff0c;反之亦然。出于不同的目的而使用相同的锁&＃xff0c;子类和基类可能会互相绊住对方的脚。

有条件的线程安全&＃xff0c;需要在文档中说明&＃xff1a;在执行某些方法调用序列时&＃xff0c;它们的客户端程序必须获得哪把锁。

是否要用延迟初始化&＃xff0c;要看具体情况。延迟初始化降低了初始化类或者创建实例的开销&＃xff0c;却增加了访问被延迟初始化的域的开销&＃xff08;会影响初次访问的性能&＃xff09;。若非必要&＃xff0c;就不要使用延迟初始化。

一切都是权衡&＃xff0c;很多服务器系统会在起到后&＃xff0c;提前初始化一些大对象后&＃xff0c;或者进行一定程度的预热后&＃xff0c;再对外提供服务。

如果出于性能的考虑要对静态域使用延迟初始化&＃xff0c;推荐使用 lazy initialization holder class 模式&＃xff1a;

private static class FieldHolder {static final FieldType field &＃61; computeFieldValue();}static FieldType getInstance() {return FieldHolder.field;}

如果出于性能考虑&＃xff0c;要对实例域进行初始化&＃xff0c;就使用双重检查模式 double check idiom&＃xff1a;锁 &＃43; volatile。

private volatile FieldType field;FieldType getInstance() {FieldType result &＃61; field;if (result &＃61;&＃61; null) {synchronized (this) {result &＃61; field;if (result &＃61;&＃61; null) {field &＃61; result &＃61; computeFieldValue();}}}return result;}

局部变量 result 的使用&＃xff0c;能够提升 25% 的性能。

如果可以接受实例域的重复初始化&＃xff0c;可以使用单重检查模式 single check idiom&＃xff1a;

private volatile FieldType field;FieldType getInstance() {FieldType result &＃61; field;if (result &＃61;&＃61; null) {field &＃61; result &＃61; computeFieldValue();}return result;}

去掉 volatile 可以加快某些架构上的访问&＃xff0c;代价是增加了额外的初始化&＃xff0c;这种模式叫 racy single check idiom&＃xff0c;在 String 的散列码字段 hash 的初始化中用到。

private int hash; // Default to 0public int hashCode() {int h &＃61; hash;if (h &＃61;&＃61; 0 && value.length > 0) {char val[] &＃61; value;for (int i &＃61; 0; i 31 * h &＃43; val[i];}hash &＃61; h;}return h;}

任何依赖于线程调度器来达到正确运行或者性能要求的程序&＃xff0c;很可能都是不可移植的。要编写健壮的、响应良好的、可移植的应用程序&＃xff0c;最好的办法是设置合理的线程数目&＃xff0c;减少无意义的工作&＃xff08;比如 busy-wait&＃xff09;。

不要依赖 Thread.yield 或线程优先级&＃xff0c;它们不具有可移植性&＃xff0c;也就是说在不同 JVM 上表现不同。

线程组的实现由很多问题&＃xff0c;使用线程池 executor 即可。